has 8 seconds proven to always be enough time for this?

So far yes. Check this out too.

Yes the 8 second delay is really not a clean way to do this (what if the CI is much slower than local, or the opposite? One side or another you're waiting for longer than you should and it's just overall hacky).

We used this approach to get something working and opened an issue on regtest-toolbox thinking maybe a solution could be added there, but I think @ItoroD's idea of polling the Electrum server until it sees the transaction or block is probably the best way to do this test-side.

I'll add the polling loop here and test locally between runs to see the general feel for it (maybe looping on 1/10th of a second is too much? Maybe not). But in any case I'll use that approach here, and we should clean up the JVM tests as well.

yeah the polling loop sounds cleaner, I like it

I ended up with this:

// Wait for the Esplora client to see the transaction. Try 5x per second for 20 seconds.
repeat(100) {
    if (esploraClient.getTx(txid) != null) return@repeat
    delay(200.milliseconds)
}

Which usually takes between 10 and 30 loops to complete on my machine.

return@runBlocking breaks out of the loop.

return@runBlocking is nice but I think it would exit the whole test body here not just the polling loop?

Ahh that's what I used in my fork test I think the reason I didn't notice was the test still said success although I have unknowingly existed the program. Blinded by success 😁. Really good catch @reez

This is what I meant to do here return run not runBlocking

Good catch @reez. I updated with:

for (i in 0..99) {
    if (esploraClient.getTx(txid) != null) break
    delay(200.milliseconds)
}

which accomplishes the stated goal of only running the required number of iterations.

LGTM now 👍